Description

This PR implements notify_only support for policies, which can also be used in defaults.yml to put an entire account into notify-only mode. This is controlled by a notify_only boolean top-level policy key, which policygen then handles and strips out when generating the final custodian YAML files.

The current functionality of notify-only is as follows:

• The comment / comments / description fields will be prefixed with the string NOTIFY ONLY:
• If the policy has a tags list, a notify-only tag will be appended to it.
• All tagging actions will have the string -notify-only appended to their tag names, to automate the above-described transition. Specifically:
  • Any mark or tag actions in the actions list will have the string -notify-only appended to their tag or key values (if present) or appended to every item in their tags list (if present). If none of the above are present, the tag item will be set to custodian's DEFAULT_TAG value, with -notify-only appended.
  • Any mark-for-op actions will have the string -notify-only appended to their tag value. If they do not already have a tag value, it will be set to custodian's DEFAULT_TAG value, with -notify-only appended.
  • Any remove-tag / unmark / untag actions wukk have the string -notify-only appended to all items in their tags list.
• All notify actions will have their violation_desc, if present, prefixed with NOTIFY ONLY:. Their action_desc, if present, will be prefixed with in the future (currently notify-only).
• All other action types, not listed above, will be removed from the policy. We enforce notify-only by only retaining specifically whitelisted actions in the policy.

Testing Done

1. Complete unit test coverage.
2. Ran a dry-run internally on one of our accounts. Ping me on Slack, or see the card for this, for a link to the diff.